From Saturday, Nov 23rd 7:00 PM CST - Sunday, Nov 24th 7:45 AM CST, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

NI TestStand Idea Exchange

Top Authors

User

Kudos

Post an idea

Since TestStand 2019, it's possible to configure an action step with a LabVIEW Module to switch between using a source VI and using the same one but compiled into a LabVIEW Packed Project Library (PPL).

The option, accessible in two ways, is called "Always run VI in Packed Project Library".

That's a neat possibility since it's allow to switch between a development version with easy debugging of a classical VI, and an optimized and locked production version with PPL.
One non compiled VI
One compiled VI into a PPL
One LabVIEW project
One TestStand step

However, when LabVIEW Adapter is set to Run-Time, a tight coupling between the compiled VI and the non-compiled VI is maintained for no reason.

Example 1)
-A VI is developed and compiled on a development machine A
-It is called as the module of an action step
-The VI, the PPL, the .lvproj and the .seq are pasted on a production machine B with fresh installations of LabVIEW and TestStand
-LabVIEW Adapter set to Run-Time on machine B
-Always run VI in Packed Project Library set on machine B
--> The execution will not start, since the classical error -17600 appears on the call. The reason is because the LabVIEW cache of the machine B does not contains data from the .lvproj. Simply opening then closing the .lvproj updates the LV cache, which solves the issue. However, it makes no sense to depend of the LabVIEW development environment on this production machine since the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled.

Example 2)
-LabVIEW Adapter set to Run-Time
-Always run VI in Packed Project Library
--> If source VI is deleted, it takes a long time to preload the modules. See here

Proposition :
When the LabVIEW Adapter is set to Run-Time and "Always run VI in Packed Project Library" is enabled, it should be possible :
- To not install the LabVIEW development environment (only the LV Run-Time)
- To keep only the PPL (and eventually the .lvproj) and to delete the source VI (no source code on production machine)

When test cycles run and fail for some reason, sometimes LabVIEW will either crash or get hung and wont close.

Even when exiting or restarting Teststand, LabVIEW does not close properly...or re-open properly, locking any HW resources. Non-technical savvy operators are unsure / do not know what to do.

If the operators were notified with a pop-up informing them of a windows restart is needed to clear LabVIEW PRIOR to even the login prompt, that saves a lot of false start/false fails and headaches.

We have implemented this in the "FrontEndCallbacks.seq" and works great for false-fail runs.

Teststand should have this implemented built-in.

View All (1)

Add progress bar option to Wait step

The built-in Wait step currently causes TestStand to simply stop at that step until the specified period has elapsed. For steps longer than a few seconds, it would be nice to have some sort of indicator to show how much time is left to wait (and to show that the computer hasn't locked up on those waits that are more than 15 seconds).

It would be really nice to have a check box option to show some sort of wait indicator, even if it was simply using the progress indicator in the lower right corner of the screen (something that simple could even just always be enabled).

On a related note, could the progress bar be made wider so that there is more resolution as to how much progress has been made? If there was a ten minute wait for something, the bar would be moving very slowly and hard to tell progression was being made.

View All (1)

When user opens the Offline Processing Utility and at the same time starts to type on the keyboard the user can accidently rename the profile.

(Attached a screen-recording to visualize)

It would be great if there was no selected row or column when starting/opening ORPU. The renaming of the profile disturbs the production since the database logging will not work as expected.

When we start ORPU we already have the '/tray' enabled but somehow its still possible to accidently rename the Profile.

Almost all of our analog measurements are specified in %: example

a Power Supply DMM measurement limit is 24.00Vdc +/- 5%

We typically have 100+ measurements like this in a project

Why not include it in the default step types as an optional selection?

I sure would use it, so would my team.

I agree that it should not alter existing programs using the default step, but I believe that this feature should have been in Teststand when it was first released.

I have run across this in both analog measurements, and the results from an ADC

Think a limit of 0x234 +3%, -7%

View All (4)

The TestStand API doesn't provide a simple, robust mechanism allowing developers to programatically run sequences outside of the ActiveX UIs.

On many an occasion I've wanted to wrap the following basic functionality:

Run a specific sequence file (with or without a [typically custom] process model)
Wait for it to complete.
Retrieve the result.

It's something I've needed to do in all of the following situations:

Integrating into a customer's existing framework
Integrating into my own automated test framework
Providing a simple API to a customer
Creating customized UIs that rely on UI messages and events rather than the ActiveX Controls

The solution I've ended up defaulting to in the past has been some variation on:

Start with the full-featured C# UI.
Scrape out all visible ActiveX Controls, and hide the window so that it's running in the background.
Integrate a TCP/IP (or equivalent) client into the application that has the ability to listen for requests and then implement them through the AxApplicationMgr.
Build a TCP/IP server assembly that launches the client application and exposes the necessary API for simple interactions.

The approach above is time-consuming, error-prone, and feels like a hack -- but given that TestStand does not expose any easy mechanism for simply running a sequence, this is what I've ended up having to resort to.

Handling arrays in TestStand is pretty limiting and more often that not you have to pop into a code module to perform any sort of array handling.

The following is the default functions that can be used in expressions:

[Array
GetArrayBounds(array, lower, upper) Retrieves the upper and lower bounds of an array.
GetNumElements(array) Returns the number of elements in an array.
InsertElements(array, index, numElements) Inserts new elements into a one-dimensional array.
RemoveElements(array, index, numElements) Removes elements from a one-dimensional array.
SetArrayBounds(array, lower, upper) Changes the bounds of an array.
SetNumElements(array, numElements) Sets the number of elements in a one-dimensional array.

]

I would like to see this expanded to avoided have to resort to using code module.
The following is some suggestion:

Array Subset function
Array Max & Min
Replace Array Subset function
Search 1D Array
Sort 1D Array

regards

Ray Farmer

When loading large sequence files, TestStand does not display progress and appears to "lock up" both TestStand and the LabVIEW OI. Sequences with hundreds of steps can take minutes to load. Operators often incorrectly conclude the application has stopped respoding during long pre-loads.

I am suggesting to implement a responsive progress display, allowing the LabVIEW OI to proceed execution, and post the following UI Messages during step pre-load.

UIMessageCodes

UIMsg_ProgressPercent–(Value: 11) TestStand step modules post this message to the user interface to notify it to update its progress indicator associated with an execution.
UIMsg_ProgressText–(Value: 12) TestStand step modules post this message to the user interface to notify it to update its progress message associated with an execution.

Expression Variables

I was in the middle of creating an ugly expression that was parsing a string and building a file path from other standard file paths and realized that I can clean up the expressing by creating a few local variables. But then I thought do I really want to create these local variables in my sequence that only exist for the purpose of this one expression. Then I thought, what if I can define a variable within the expression itself, kind of how a variable is defined in C or something similar. It only exists during the evaluation of the expression.

Hello,

For the moment the runtime error handling can be managed by using ...

Runtime error options
Ignore runtime error flags
Manually, for action steps, by handling actions returns

It should be nice to add such a kind TRY CATCH block, in order to modify the error handling in a local section of a sequence.

TRY

Steps ...

CATCH

case 35 // Error code = 35

end

case default // All other error codes

end

End

Doing so, could be a way to handle runtime errors, in an other way that the global configured way.

Manu.

Because of the way .NET applications and assemblies are invoked in TestStand they are a child process of TestStand. This means that they share TestStand's resources. For most applications this is not an issue but if the application or library being instrumented by TestStand is resource intensive this creates a significant problem. In the scenario that served as the impetus for this suggestion we saw performance 1/10 that when running the target application outside of TestStand.

To correct this I recommend the .NET adapter architecture be changed or be able to be configured such that instead of directly instantiating target applications a call to create an object with a .NET adapter would create a separate process that consisted of a TestStand WCF client wrapper process that would host the target .NET process and communicate with the parent TestStand instance via WCF.

Here is a simple block diagram of the intended architecture:

Add some OOP feature to a seqeunce

It would be nice to make Sequences public or private within a SequnenceFile.

With this you where able to make powerful SequenceFiles librarys. The biggest advantage of this

is you can show the consumer of the library only the "important" public sequences. The

private ones where invisible. This will help to avoid errors.

Regards

juergen

Improved Round Function

I have a bunch of times that I need to round a numeric variable in TestStand

example: Locals.A = round(Locals.B)

However, it's actually more complicated than that because I need to round it at the Nth position after the decimal point (for example). This means my expression becomes something like Locals.A = pow(10,-Locals.Digits) * round (Locals.A * pow(10,Locals.Digits) ) (for Locals.Digits == 3, this means that Locals=A becomes 0.123 when Locals.B is 0.1234)

This is a lot more code than I really want to write. If I am doing the same thing in MS Excel, I just say $B5 = round($B4,$A$1) or something like that. Notice how the digits of precision to round to is built into the round function. I'd love if TestStand round function could be expanded the same way

Round(Number, [option], [Digits])

The output messages are a good way of sending status messages from the test solution to the end user. However the control is not available as one of the controls that can be added to user interfaces.

Can this control be made available to be quickly added to a UI and linked to the execution view manager.

Also adding some kind of API interface to be able to capture these messages to a log file would remove the need to implement any custom logging mechanisms. If possible ability to open multiple file logs within the engine at the same time with each file given some kind of filter rules (for example Severity=”error” or ExecutionId=5). If logs had to be attributed to an execution ID then they could automatically be closed when the execution ended, otherwise the user would have to manually close each file which could get forgotten and TestStand end up with lots of open file references.

Shortcut to 'Unload All modules'

Custom TestStand UI suggestion.

I would like the same functionality as with Sequence Editor when double clicking on Sequence Call step (already configured) and it goes into the Subsequence directly and you can view the SubSequence.

I would like to see that functionality in the TestStand Custom UI when double clicking on the Sequence Call step with Sequence View Manager and it goes into the Subsequence so it can it viewed.

This would come in handy when debugging a subsequence and setting break points in the subsequence and then viewing variables during execution.

View All (2)

When I get called to look at an issue that has occurred with a test, the account logged into TestStand is typically a restricted user (i.e. Operator). Since the Operator account has very limited options, in order to really do much immediate troubleshooting I need to stop the test and re-run it in the Administrator account. At best this is inconvenient and inefficient if the spot the error occurred is late in the test. However, it is extremely frustrating when it's an intermittent run-time error and I can't do any real-time debug because Operator is logged in. The only real alternative I can think of (when the problem is intermittent) is to leave it logged in as Administrator so I can debug whenever it happens to occur. This is not really an acceptable practice in most cases.

It would be fantastic if there were an override that let's an Administrator provide the proper credentials to perform the desired task that would normally be off-limits to the Operator. The basic premise of this suggestion is similar to the functionality within Windows; if you try to connect to a secured location or perform a task that requires administrator privileges, a dialog box pops up asking you to enter authorized credentials.

I run into many situations where I wish this feature was present. The issue is not always within TestStand (could be a database connection issue, etc.), but it is TestStand that throws the error and in Operator mode the only option is "Run Cleanup". Significant time, effort, frustration, and efficiency could be saved if I could simply enter my credentials as an administrator to perform the tasks I need to do.

Regards

On an unrelated side note, I find it humorous that "TestStand" is considered a misspelled word when using the forum spell checker. 🙂

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

NI TestStand Idea Exchange

Review all idea Exchange and Update status

Improvement of LabVIEW Packed Libraries TestStand options

Teststand should (Optionally) block startup when LabVIEW is already in memory

Add progress bar option to Wait step

No selection of any field inside Offline Processing Utility (ORPU) when application starts

Add the capability to express limits in +/-% of expected value in all limits

Quick Preloading Modules when no source for PPL

API that doesn't rely on ActiveX UI Components

Expand on the default Array Functions

Ability to Launch Version Selector from Error Dialog

Add Progress Indicators During Pre-Load

Expression Variables

Try Catch block to handle runtime errors ...

Host .NET processes outside of TestStand's application space

Add some OOP feature to a seqeunce

Improved Round Function

Make Output panel available as UI ActiveX Control

Shortcut to 'Unload All modules'

Double Clicking on Sequence Call Step in Custom UI

Implement "Administrator Override" option